1. Field of the Invention
The present invention relates to the field of electronic system design and, more particularly, to a hardware co-simulation interface for use with programmable logic devices and software-based simulation tools.
2. Description of the Related Art
Electronic circuit designs can be constructed, simulated, debugged, and translated into electronic hardware using a High Level Modeling System (HLMS). Typically, an HLMS is implemented as a software-based design tool which provides blocks that can be combined to build an electronic circuit. A block refers to a high level software construct that represents a particular circuit function, such as multiplexing, addition, multiplication, or the like. Blocks may have ports that can produce and consume signals, and may be arranged within the HLMS to form a circuit and/or system. Communication among the blocks can be represented by wires, or signals, that graphically link the blocks. The design may be simulated within the HLMS once it is constructed. Some HLMS tools can generate a hardware implementation from the block representation of the circuit design. For example, an HLMS can generate the bitstream necessary to program a field programmable gate array (FPGA) or can generate the hardware description language (HDL) files necessary to specify the hardware design.
One example of an HLMS is System Generator for DSP™, available from Xilinx, Inc. of San Jose, Calif. System Generator for DSP™ is a system level modeling tool that facilitates FPGA hardware design. System Generator for DSP™ provides a wide range of blocks that can be automatically compiled into a design suitable for an FPGA. Among these blocks are high level abstractions that implement complex functions, including digital signal processing as well as communication and control logic. In addition, access to underlying FPGA resources can be provided through low level block abstractions that facilitate the construction of highly efficient FPGA designs.
An electronic design typically is simulated in an HLMS using program logic that models block behavior. It also is possible to incorporate circuit designs, which already have been implemented in hardware, into HLMS simulations. To do so, the computer system hosting the HLMS preferably is connected to the device under test (DUT) via a high bandwidth communication channel, although a low bandwidth communication channel may be used in cases where co-simulation runtime is not of the essence. The DUT typically is a design implemented within a programmable logic device (PLD) such as an FPGA. The PLD is installed on a hardware platform which is coupled to the host computer system via a communication link. The process of running a simulation involving a hardware platform and a software platform working cooperatively with one another is referred to as hardware co-simulation, or simply co-simulation, as used herein.
There are several different types of interfaces available for use with co-simulation environments. For example, co-simulation interfaces can be implemented using the Joint Test Action Group (JTAG) or IEEE Standard 1149.1 communication protocol or as Peripheral Component Interconnect (PCI) connections. In addition to JTAG and PCI interfaces, it is also possible to perform co-simulation using an IP/Ethernet-based interface. Typically, an IP/Ethernet-based interface utilizes a multilayer network protocol stack. As such, an IP/Ethernet-based interface can provide the flexibility, interoperability, and extensibility commonly expected from the IP/Ethernet-based networks in existence today.
While an IP/Ethernet-based interface does provide significant flexibility, a fully capable IP/Ethernet interface carries a large amount of overhead. A fully capable IP/Ethernet co-simulation interface, for example, typically has the ability to handle networking complexities such as address resolution, switching and routing, system configuration, collisions, and congestion. A fully enabled IP/Ethernet-based interface also requires the use of a protocol stack on the host as well as on the PLD with which the host communicates.
When an IP/Ethernet connection is used for co-simulation, functions such as address resolution, translation and routing, system configuration, collisions, and congestion can degrade the speed of co-simulation. Additionally, implementing a protocol stack on a PLD, such as an FPGA, can be costly in terms of the hardware resources that are required. For example, a network protocol stack implementation on an FPGA usually requires the use of a soft or embedded processor in the fabric of the device. Another challenge of a fully capable IP/Ethernet co-simulation implementation on a PLD is that it is difficult to maintain the speed of “in-fabric” packet processing at the same level as the speed of the IP/Ethernet connection itself.
It would be beneficial to implement a co-simulation interface which overcomes the deficiencies described above.